這篇是針對昨天的「行前會議」的「如果需求改變」做的一個說明。
通常在專案開始前，除非是一個非常小的專案，不然我還是多少會跑一次這個思想實驗，以便設計出最佳化的資料流。
若是說 FID 跟以往的開發模式最大的不同是什麼，我想應該就是「不確定性」。
不要誤會，當然需求必須要先確定，才能進入開發，但是在確定需求之前，我們會經歷一個推敲出需求的過程，
這個過程，非常有趣。
我們來模擬一邊，假設我們要做一個公車到站的 AP，這個 AP 有幾個用戶情境：
好了，這就是我們收到的第一手材料，現在要來設計一個 AP，滿足這個專案。
要記得，這就是我們所有的資訊，我們不會有更多的資訊，我們只能透過這些資訊，來推敲出需求。
接下來，我們會針對前後端做設計，若沒有特別說明的話，我們或許會這樣設計：
所以我們猜測，需要有以下幾個模塊：
這個 AP 是用在什麼城市？台北市？新北市？台中市？還是其他城市？
所以還隱藏了一個需求，就是我們要能夠切換城市，來看到不同城市的公車資訊。
所以其實是：
再承接我們一開始的設計的。
其實還有很多隱藏背後的模塊需要建立，大家可以再想想還有什麼我們沒有想到的。
本來，我們顯示公車的到站時間，是用文字顯示，但是我們發現，這樣不夠直覺，所以我們決定改成用圖片顯示，所以會是一張地圖，
然後配合顏色，來顯示公車的到站時間。
那我們就必須在公車站牌的資訊中，加入一個欄位，來記錄公車站牌的經緯度，這樣我們才能夠在地圖上顯示出來。
公車到站的資訊，本來就是一個 API，但後來又說，我們會依據「天氣」來調整公車的到站時間，所以我們必須要有一個天氣的 API，
並且這些 API 都是由第三方提供，我們只能夠呼叫，不能夠修改。
後段也不會有太大的變動，但是前端就必須要修改了。
這個 AP 必須在有網路的情況下才能夠使用，但是我們發現，有些地方的網路不太穩定，所以我們必須要有一個離線模式，讓使用者可以在沒有網路的情況下，使用這個 AP。
以上的變動，只是我們在設計的時候，所能夠想到的，但是在開發的過程中，我們會發現更多的變動。
這些不確定最後都會幫我們完善這個需求背後的意圖和目的，所以我們不需要害怕，只需要接受，並且不斷的調整我們的設計。
從以上的例子，我們可以不難看出，主線和變動的關係。
按照這樣的邏輯，我們可以把主線想成是一個「穩定的」需求，而變動就是「不穩定的」需求。
並利用我們偉大的設計模式，來處理這些變動，大家可以想想看，我們可以用什麼模式來處理這些變動。
若以上面的例子，如果我們收到需求就去實作，會是這樣：
大概會分成幾個模塊，然後顯示的流程如下：
每個人在寫程式的時候，其實都是經過精心設計的，最後變成一個債，都是過程中出了事，需求闖的禍，為了要加入車站整修的資訊，所以我們做了一下修改。
但如果我們理解，「維修」只是影響「公車站」可不可以用的其中一個因素，或許我們可以考慮這樣做，而且按照這個思路，其他會影響的模組，都可以放在這個「中間層」上
後來不知道幹嘛，還要加入政府的通知，例如跨年時候需要關閉，或者遊行的時候需要封路，沒關係，我們繼續加
那是因為，我們這個AP要轉移到別的國家用，其他國家的公車都很準時，而且不需要加入天氣，那只需要拿掉那個天氣「中間層」即可。
我們不會直接從「需求」中看出「主線路」，反而是透過不斷的推敲和反覆的驗證來測試出，那一些「區塊」是必經之路，那一些東西，是「可變」的。
百分之九十的技術債都是「堆疊」而成，我們可以怪需求改了又改，但是如果前提作業做了足夠多的思考工作，會大大減少日後修改的難度。
那麼一來，我們終於確認需求了，我的意思是，我們確認我們的程式應該怎麼寫。
對於客戶來說，他們的需求，就是看到公車資訊。
但是對於工程師來說，需求是：
iThome鐵人賽
看影片追技術